\chapter{Blide}

Questo capitolo presenta \emph{Blide} (Blite Integrated Development
Environment) uno strumento che racchiude un ambiente di esecuzione locale e
fornisce un'interfaccia grafica che permette di svolgere in maniera integrata
tutte le operazioni legate allo sviluppo di programmi Blite. 
% Nella prima parte
% del capitolo vengono descritte le caratteristiche e le funzionalità
% dell'interfaccia, mentre nella seconda parte se ne presetano alcuni
% esempi di utilizzo.
In questo capitolo vengono descritte le caratteristiche e le funzionalità
dell'interfaccia e successivamente viene presentato un caso d'uso ispirato ad
un esempio presentato nella specifica di BPEL 1.1 \cite{BPEL10Spec}.

\section{Un IDE per Blite}

Per verificare se uno strumento è funzionale la cosa migliore da fare
è provarlo. In tal senso per verificare se il linguaggio e il motore di
esecuzione realizzati risultino veramente utilizzabili è stato sviluppato un
vero e proprio IDE che permetta di scrivere rapidamente e testare, tramite
l'esecuzione di simulazioni, i programmi Blite.

% Oltre al motore di esecuzione si è realizzato un vero e proprio IDE per
% sviluppare i programmi Blite. 
Questo strumento prevede la possibilità di
gestire i file con le definizioni dei processi, editarli, compilarli e metterli
in esecuzione. E' presente anche la funzionalità per visualizzare, tramite una
rappresentazione grafica, l'esecuzione delle istanze di processo.

Blide è stato realizzato tramite il progetto \emph{NetBeans Platform}
\cite{NBPlatSite}, un framework studiato per facilitare lo sviluppo di
applicazioni Java con interfaccia grafica. E' stato scelto tale progetto per la sua
completezza e per il modello architetturale offerto. 

NetBeans Platform permette allo sviluppatore di realizzare le proprie
applicazioni componendo diversi moduli, ciascuno dei quali offre una
funzionalità specifica. La modularizzazione molto fine e la gestione
formale delle dipendenze permettono di costruire applicazioni riuscendo a
selezionare in modo molto mirato solamente i moduli realmente necessari e
quindi a mantenere limitate le dimensioni complessive dell'applicazione. 
Per una presentazione approfondita di NetBeans Platform si consulti
\cite{RichClientApp}.

\begin{figure}[t!]
\begin{center}
\includegraphics[scale=0.60]
{blide/dia/Blide1}
\caption[Blide Schermata]{Come si presenta Blide al primo avvio.}
\rule{7cm}{0.01cm}
  \label{fig:blide1}
\end{center}
\end{figure}

In Figura \ref{fig:blide1} è presentata l'interfaccia di Blide al primo avvio. 
Oltre alle consuete barre dei menù e dei pulsanti posizionati in alto,
l'applicazione presenta quattro aree distinte:

\begin{enumerate}
  \item Un pannello identificato dall'etichetta \emph{``Favorites''} che
  permette di accedere al filesystem e organizzare i file ``preferiti''
  in raggruppamenti logici.
  \item Un pannello identificato con l'etichetta \emph{``Engines''} in cui è
  possibile accedere ai motori di esecuzione attualmente disponibili, alle
  definizioni di processo e alle istanze create da queste.
  \item Un'area centrale in cui verrano visualizzati gli editor con i file
  sorgenti e le rappresentazioni grafiche delle istanze eseguite.
  \item Un pannello in basso in cui è possibile visualizzare l'output di
  sistema, come per esempio l'esito della compilazione dei programmi Blite.
\end{enumerate}

Di seguito andiamo ad analizzare più nel dettaglio queste aree e altre
funzionalità dell'interfaccia di Blide.

\subsubsection*{Favorites - Gestione dei Sorgenti Blite}

\begin{table}
\begin{center}
\begin{tabular}{| c | c |}

\hline
\parbox[c][1.8cm][c]{0.8cm}{\includegraphics{blide/dia/biconto}} 
&
\parbox[c][1.8cm][c]{0.7\textwidth}{File Blite che deve essere compilato. Il
file non è mai stato compilato o ha subito modifiche dopo l'ultima
compilazione.}\\ 

\hline
\parbox[c][1.8cm][c]{0.8cm}{\includegraphics{blide/dia/biconko}} 
& 
\parbox[c][1.8cm][c]{0.7\textwidth}{File Blite che presenta errori di
compilazione. L'ultima compilazione eseguita sul file ha riportato errori.}
\\

\hline
\parbox[c][1.8cm][c]{0.8cm}{\includegraphics{blide/dia/biconok}}
& 
\parbox[c][1.8cm][c]{0.7\textwidth}{File Blite compilato con successo. Delle
definizioni presenti nel file sono disponibili i modelli statici.}\\

\hline
\end{tabular}
\caption{Icone associate ai file Blite con estensione \texttt{.blt}}
\rule{7cm}{0.01cm}
\label{tab:bficons}
\end{center}
\end{table}

Abbiamo detto che quest'area permette di accedere al filesystem, in realtà
non offre un'unica visione dell'albero come i consueti file manager, ma
permette in pratica di visualizzare direttamente più sotto-alberi del
filesystem. Di fatto l'utente può selezionare un direcotry e con la funzione \emph{``Add to
Favorites\ldots''} aggiungere tale directory, con tutto il suo sotto albero,
come una nuova radice che compare direttamente nel pannello. In questo modo l'utente
si può creare una specie di \emph{Bookmarks} alle directory a cui accede
maggiormente e in cui probabilmente ha salvato i file di lavoro. Da notare che
tali configurazioni vengono salvate automaticamente dall'applicazione e al
successivo riavvio l'utente si troverà mantenute le scorciatoie alle directory
preferite. Al primo avvio l'applicazione mostrerà come unica risorsa favorita
la directory ``home'' dell'utente.

\begin{figure}[h]
\begin{center}
\includegraphics[scale=0.65]
{blide/dia/BlideFavo}
\caption[Il pannello ``Favorites'']{Una direcory con alcuni sorgenti Blite.}
\rule{7cm}{0.01cm}
  \label{fig:blideFavo}
\end{center}
\end{figure}

All'interno degli alberi di Favorites i file con estensione
\texttt{.blt} vengono riconosciuti come file sorgenti Blite e vengono
visualizzati con icone speciali. Inoltre l'applicazione decora tali icone in
base al fatto che i file necessitino compilazione, siano stati compilati con
successo o presentino degli errori che ne abbiano compromesso la compilazione.
In Figura \ref{fig:blideFavo} è rappresentato il pannello in cui è stato aggiunto nei
favoriti la directory \texttt{data}, questa contiene una serie di file sorgenti
Blite che vengono visualizzati con le opportune icone. In Tabella
\ref{tab:bficons} sono rappresentate le varie icone associate ai file Blite con
il riferimento alla loro semantica.
\\

\begin{table}[t]
\begin{center}
\begin{tabular}{|c| p{0.7\textwidth}| }
\hline

\parbox[c][1.7cm][c]{1cm}
{\includegraphics[scale=0.8]{blide/dia/build24}} 
& Compilazione del codice Blite.\\

\hline 

\parbox[c][1.7cm][c]{1cm}{\includegraphics[scale=0.8]{blide/dia/deploy24}} &
Istallazione dei Deployment contenuti nel file sugli Engine.\\

\hline

\parbox[c][1.7cm][c]{1cm}{\includegraphics[scale=0.8]{blide/dia/undeploy24}} &
Rimozione dei Deployment contenuti nel file dagli Engine.\\
\hline

\end{tabular}

\caption[Azioni che possono essere eseguite su un file Blite]{Azioni che
possono essere eseguite su un file Blite.}
\rule{7cm}{0.01cm}
\label{tab:blideactions}
\end{center}
\end{table}

Su ogni nodo rappresentante un file Blite possono essere eseguite diverse
azioni. In particolare tali azioni, come è consuetudine nelle applicazioni con
interfaccia grafica, possono essere eseguite in modi diversi: dai menù a
discesa della \emph{``Menu Bar''}, che si trova nella parte alta della finestra,
dai menù contestuali che si aprono premendo il tasto destro del mouse su
un oggetto selezionato e dai bottoni che si trovano nello spazio subito sotto
la menù bar detto \emph{``Tool Bar''}. In Figura \ref{fig:blideCMenu} è rappresentato il
menù contestuale che viene visualizzato premendo il tasto destro su un file
Blite, che nel caso specifico deve essere ancora compilato, per cui risulta
abilitata l'azione \emph{``Compile''}, mentre le azioni \emph{``Re/Deploy''} e
\emph{``Undeploy''} sono ovviamente disabilitate, in quanto non è ancora
disponibile un modello di definizione da poter istallare. In generale
tutta l'interfaccia è stata realizzata secondo il paradigma
\emph{Context-Sensitive Interface}, per cui le sue
varie parti sono sensibili allo stato degli oggetti che si trovano a gestire.

\begin{figure}[t]
\begin{center}
\includegraphics[scale=0.70]
{blide/dia/BlideCMenu}
\caption[Menu Contestuale su di un File Blite]{Facendo click con il tasto destro
su un nodo rappresentante un file Blite, si apre un menù contestuale che
visualizza le azioni che l'utente può compiere sul file stesso. Da osservare
come siano abilitate solo le azioni applicabili, di fatto viene realizzato il
paradigma \emph{Context-Sensitive Interface}, secondo cui ogni componente
dell'interfaccia è sensibile allo stato degli oggetti contestuali.}
\rule{7cm}{0.01cm}
  \label{fig:blideCMenu}
\end{center}
\end{figure}

Oltre che nel menù contestuale che si apre sui file Blite, le operazioni che
risultano più frequentemente eseguite dall'utente, \emph{``Save''},
\emph{``Compile''}, \emph{``Deploy''} e \emph{``Undeploy''}, sono state rese
disponibili tramiti pulsanti, facilmente raggiungibili, posizionati nella Tool
Bar:

\begin{center}
\includegraphics[scale=0.70]
{blide/dia/BlideFileToolBar}
\end{center}

Si osservi come anche questa parte dell'interfaccia risulti sensibile al
contesto, cioè in questo caso al file attualmente selezionato o visualizzato
nell'editor, e come siano attivati solamente i pulsanti, le cui azioni siano
attualmente applicabili. 

In Tabella \ref{tab:blideactions} sono ricapitolate le azioni eseguibili su file Blite con le
icone presentate nell'interfaccia.

\newpage

\subsubsection*{Editing e compilazione del codice Blite}
Facendo doppio click, o usando l'azione contestuale \emph{``Open''}, su un nodo
degli alberi di Favorites rappresentante un file Blite, si apre un pannello di
editing nell'opportuna sezione dell'interfaccia grafica. 

Per creare un nuovo file invece si devono eseguire i seguenti passi:

\begin{enumerate}
  \item Nel pannello Favorites, selezionare la directory in cui si desidera
  creare il nuovo file.
  \item Premere il tasto destro e visualizzare il menù contestuale.
  \item Su di questo posizionarsi sulla voce \emph{``New''} in modo da
  visualizzare il sottomenù associato:
\begin{center}
\includegraphics[scale=0.60]{blide/dia/BlideNewFile}
\end{center}
  \item A questo punto le possibilità sono due:
\begin{enumerate}
  \item Creare un file vuoto, selezionando la voce di menù \emph{``Empty
  File''}. In questo caso si aprirà una finestra in cui l'utente potrà digitare
  il nome del nuovo file comprensivo dell'estensione \texttt{.blt}.
  \item Utilizzare un file di esempio da cui iniziare a
  sviluppare il proprio programma Blite scegliendo la voce \emph{``All
  Templates \ldots''}. In questo caso tramite un ``Wizard'' l'utente potrà
  scegliere fra una serie di file che possono costituire un punto di partenza
  (Template) per scrivere il proprio codice.
\end{enumerate} 
\end{enumerate}

Abbiamo mostrato come aprire un sorgente Blite all'interno di un editor. Blide
fornisce un editor specializzato per scrivere programmi Blite, che mette a
disposizione le funzionalità specifiche di:

\begin{itemize}
  \item \emph{Syntax Highlight}: Tramite la grammatica formale, presentata
  nel Capitolo 2,  è stato possibile realizzare una tecnologia capace di 
  riconoscere la sintassi Blite ed evidenziare in maniera opportuna le parole
  riservate  e i costrutti specifici del linguaggio. Tale tecnologia si basa
  sul progetto \emph{``Generic Languages Framework (GLF)''} \cite{GLFSite}, che
  mette a disposizione un modulo per NetBeans Platform con cui è possibile sviluppare 
  il supporto ad un linguaggio di programmazione all'interno delle proprie 
  applicazioni.
  
  \item \emph{Autocompletamento}: L'editor dei file Blite assistono
  l'utente nella scrittura del codice andando a completare automaticamente
  alcune parti del codice. In particolare l'editor inserisce automaticamente i
  delimitatori di chiusura dei blocchi. Per esempio, all'utente basterà digitare
  la stringa \texttt{seq} e il sistema inserirà automaticamente la chiusura
  inserendo il corrispettivo \texttt{qes}. Inoltre anche le operazioni di
  invocazione e ricezione sono completate automaticamente, digitando per
  esempio semplicemente la stringa \texttt{rcv} l'utente si troverà a
  disposizione l'intera struttura dell'operazione di ricezione come: 
  \verb#rcv<"on_me"> operation(x)#, e in questa potrà modificare
  le parti necessarie.
  
\end{itemize}

Abbiamo visto nel Capitolo 2, come la sintassi originale di Blite sia stata
arrichita con alcune parole riservate e come tutte le attività strutturate siano state
dotate di delimitatori di blocco. Con il supporto dell'editor tale
appesantimento sintattico non verrà avvertito dal programmatore.
  
In Figura \ref{fig:blideEditor} è raffigurato un editor con il sorgente Blite in
cui sono evidenziate tramite colori e font specifici le parole riservate e i
costrutti del linguaggio.
	
La compilazione del file visualizzato nell'editor attualmente attivo, come
detto, può essere eseguita con l'opportuno pulsante nella Tool Bar. All'utente
verrà notificato l'esito della compilazione nell'area in basso
dell'interfaccia grafica identificata con l'etichetta \emph{``Output''}. In caso di
errore tale area riporterà il messaggio opportuno e l'utente potrà direttamente
fare click su di esso per posizionare automaticamente il cursore dell'editor in
corrispondenza della linea e della colonna in cui è presente l'errore. In
Figura \ref{fig:blideCompError} è rappresentata questa situazione.

\begin{figure}[t]
\begin{center}
\includegraphics[scale=0.60]
{blide/dia/BlideEditor}
\caption[Blide, l'editor per Blite]{L'editor di Blide per con il \emph{``Syntax
Highlight''} per il codice Blite.}
  \label{fig:blideEditor}
\end{center}
\end{figure}

\begin{figure}[b!]
\begin{center}
\includegraphics[scale=0.60]
{blide/dia/BlideCompError}
\caption[Blide, feedback alla compilazione]{Feedback interattivo per gli errori
di compilazione.}
  \label{fig:blideCompError}
\end{center}
\end{figure}

\subsubsection*{Engines - Deploy ed esecuzione dei processi}

Blide è dotato di un ambiente \emph{Local Environment} per l'esecuzione dei
processi Blite. Come già detto il Local Environment permette di eseguire
localmente (in una Java Virtual Machine) più Engine e di gestire la
comunicazione fra questi simulando la rete.

Quando un file sorgente di Blite è compilato, è abilitata per questo l'azione
di \emph{``Deploy''}; a questo punto se l'utente la esegue i \emph{Deployment}
(si ricorda che nella sintassi i deployment sono individuati dai delimitatori
$\verb#{# \ldots \verb#}#$) definiti nel file vengono istallati su
opportuni Engine.

Attualmente, per velocizzare il processo di sviluppo dell'utente, l'associazione
Engine-Deployment è fatta in maniera automatica dal tool secondo il seguente
schema:

\begin{itemize}
  \item Ogni Deployment ha il proprio Engine di esecuzione.
  \item L'Engine di un Deployment viene identificato nel seguente modo: 
  
  (``nome file che definisce il deployment'' \texttt{:} ``numero d'ordine del
  dep. nel file'')
  
  Per cui, se abbiamo che un deployment è il terzo definito nel file
  \texttt{source.blt} esso verrà istallato in un engine identificato con
  l'etichetta: \texttt{source.blt:3}.
\end{itemize}

Nell'interfaccia, il pannello identificato con l'etichetta \emph{``Engines''}
visualizza un albero, la cui radice è contrassegnata come \emph{``Local
Engines''}. I nodi figli della radice rappresentano gli Engine attualmente
presenti nel Local Environment identificati con la convenzione sopra esposta;
espandendo i loro figli troviamo le definizioni di processo, e per ognuna di
essa, a livello inferiore troviamo le istanze.

\begin{figure}[t]
\begin{center}
\includegraphics[scale=0.65]
{blide/dia/BlideEngines}
\caption[Blide, feedback alla compilazione]{Rappresentazione del Local
Environment con gli Engine, in questi le definizioni di processo istallate. Per
ogni definizione sono visualizzate le istanze eseguite o in esecuzione.}
\rule{7cm}{0.01cm}
  \label{fig:blidEngines}
\end{center}
\end{figure}

In Figura \ref{fig:blidEngines} è presentato l'albero dei Local Engines.
Come si può osservare fra le definizioni istallate negli Engine, si può
distinguere le cosiddette \emph{Ready-to-Run Instances}, da queste l'utente
può avviare direttamente delle istanze tramite l'operazione contestuale
\emph{``Run''}, o tramite l'opportuno pulsante posizionato nella Tool Bar.

\begin{center}
\includegraphics[scale=0.65]{blide/dia/BlideRunInst}
\end{center}

In tabella sono riepilogati (con le rispettive Icone) i vari tipi di nodi che
si trovano nei livelli dell'albero dei Local Engines.

\begin{table}[t]
\begin{center}
\begin{tabular}{| c | p{0.5\textwidth} |}

\hline
\parbox[c][1.8cm][c]{0.7cm}{\includegraphics[scale=1,clip]{blide/dia/server}} 
& Engine.\\ 

\hline
\parbox[c][1.8cm][c]{0.7cm}{\includegraphics[scale=1]{blide/dia/defnode}} 
& Definizione di Processo.\\

\hline
\parbox[c][1.8cm][c]{0.7cm}{\includegraphics[scale=1]{blide/dia/defnodeRun}} 
& Ready-to-Run Instance.\\

\hline
\parbox[c][1.5cm][c]{0.7cm}{\includegraphics[scale=1]{blide/dia/instdef}}
& Istanza in esecuzione.\\

\hline
\parbox[c][1.5cm][c]{0.7cm}{\includegraphics[scale=1]{blide/dia/instdefok}} 
& Istanza completata.\\

\hline
\parbox[c][1.5cm][c]{0.7cm}{\includegraphics[scale=1]{blide/dia/instdefko}} 
& Instanza terminata con errori .\\
\hline

\end{tabular}

\caption[I vari tipi di nodi nell'albero Local Engines]{I vari tipi di nodi
nell'albero Local Engines.}
\rule{7cm}{0.01cm}
\label{tab:bicons}
\end{center}
\end{table}


\subsubsection*{Monitor - Visualizzazione dell'istanze}

Abbiamo visto come l'utente possa scrivere i propri programmi Blite, istallarli
ed eseguirli all'interno di un Local Environment. L'esecuzione viene avviata
facendo partire una definizione di tipo \emph{Ready-to-Run Instance}, da
questa verrà creata immediatamente un'istanza che probabilmente, invocando le
porte di start activity di altre definizioni di processo, provocherà la
creazione di altre istanze. Per esempio si consideri il seguente caso:

\vspace{0.5cm}

\begin{center}
\begin{tabular}{ccc}
\includegraphics[scale=0.75]{blide/dia/BlideMon1} 
& $\Rightarrow$
& \includegraphics[scale=0.75]{blide/dia/BlideMon2}    
\end{tabular}
\end{center}
\vspace{0.5cm}
in cui si hanno due Engine: \texttt{faulthandler.blt:1} con la definizione
\texttt{Definition 1} e \texttt{faulthandler.blt:2} con la \emph{Ready-to-Run
Instance} \texttt{Definition 1}. Quest'ultima può essere messa in esecuzione
direttamente dall'utente facendo click con il tasto destro e selezionando dal
menù contestuale l'azione \emph{``Run''}. A questo punto come si vede dalla
figura a destra vengono generate due istanze; la Ready to Run Instance ha
provocato la creazione di un'istanza della definizione di processo istallata su
\texttt{faulthandler.blt:1}.

Già dalla rappresentazione delle istanze nell'albero Local Engines si ha
un'informazione sull'esito della loro esecuzione. Come precedentemente detto
le icone riportano graficamente il fatto che un'istanza abbia concluso con
esito positivo o meno la propria elaborazione.

All'utente viene data inoltre la possibilità di visualizzare il flusso
completo di esecuzione di un'istanza. Facendo doppio click sul nodo
dell'istanza, si apre, nella zona dedicata agli editor, un pannello
che propone una rappresentazione grafica dell'esecuzione della stessa. Tale
pannello viene di seguito identificato con il termine \emph{Monitor View}.

\begin{figure}[p]
\begin{center}
\includegraphics[scale=0.65,angle=90]
{blide/dia/BlideMonitor1}
\caption[Blide: rappresentazione grafica di istanze]{Rappresentazione grafica
dell'esecuzione delle istanze e dalla loro comunicazione.}
  \label{fig:blideMonitor1}
\end{center}
\end{figure}

\begin{figure}[!t]
\begin{center}
\includegraphics[scale=0.79]
{blide/dia/BlideMonitorCode}
\caption[Blide: programma Blite]{Programma Blite associato alla
rappresentazione grafica di Figura \ref{fig:blideMonitor1}.}
  \label{fig:blideMonitorCode}
\end{center}
\end{figure}


Disponendo già di un Monitor View aperto, l'utente vi può aggiungere altre
istanze trascinandocele sopra, secondo il paradigma \emph{Drag-and-Drop}. In
questo modo è possibile visualizzare in un'unica rappresentazione grafica
l'interazione di più istanze di processo che nel loro ciclo di vita si sono
scambiate messaggi. In Figura \ref{fig:blideMonitor1} è rappresentato il
Monitor View con la rappresentazione dell'esecuzione di due istanze generate
dal codice di Figura \ref{fig:blideMonitorCode}. Si noti come la Ready-to-Run
Instance tramite la prima invocazione produca la creazione dell'istanza
derivante dalla definizione di processo, quest'ultima, con una successiva
invocazione, risponde con un messaggio di correlazione. Si osservi inoltre come
l'istanza di destra concluda con successo la sua esecuzione, in quanto
l'eccezione sollevata è gestita in un Fault Handler (è il Fault Handler stesso
che esegue l'invocazione di risposta). Quella di sinistra invece fallisce poiché
l'eccezione sollevata non è gestita da alcun Fault Handler e la stessa produce
la terminazione del ramo parallelo che era fermo in attesa di ricevere un
messaggio. 

A prima vista potrebbe sorprendere la presenza della seconda Throw (racchiusa
dal rettangolo tratteggiato di rosso) nell'istanza fallita, in quanto non
sembrerebbe prevista dal codice. In realtà essa non è altro che l'attività
Throw prevista dal Default Fault Handler (si veda la Sezione \ref{defHandelr}).
C'è sembrato che la scelta migliore per rendere la rappresentazione grafica più chiara possibile fosse
quella di rappresentare esplicitamente i Default Fault Handler, in quanto
condizionano fortemente il flusso di esecuzione, e di nascondere al contrario i
Default Compensation Handler (Empty Activity), in quanto del tutto ininfluenti.
\\

Concludiamo questa sezione dando una panoramica dei costrutti grafici utilizzati
per rappresentare i flussi di esecuzione:

\begin{tabular}{c  c}
%\hline
\parbox[c][5cm][c]{0.2 \textwidth}
{\includegraphics[scale=0.48]{blide/dia/BlideInst}} &
\parbox[c][5cm][c]{0.6 \textwidth}{Le istanze di processo
sono rappresentate tramite scatole (ombreggiate) che contengono le attvità.
Le scatole presentano alle estremità due cerchi, di cui quello in basso,
tramite la sua colorazione indica lo stato della richiesta: grigio, in
esecuzione; verde, completata con successo; rosso, fallita.}\\
\end{tabular}

\begin{tabular}{c c}
\hline
\parbox[c][3.2cm][c]{0.2 \textwidth}
{\includegraphics[scale=0.80]{blide/dia/BlideInv}} &
\parbox[c][3.2cm][c]{0.6 \textwidth}{Le attività di base (\emph{Basic
Activity}), sono rappresentate come dei quadrati con all'interno un'opportuna
icona, la cui grafica rimanda alla semantica della attività.}\\
\end{tabular}

\begin{tabular}{c c}
\hline
\parbox[c][3cm][c]{0.2 \textwidth}
{\includegraphics[scale=0.95]{blide/dia/BlideSec}} &
\parbox[c][3cm][c]{0.6 \textwidth}{L'attività di sequenza è rappresentata con
una freccia verticale, che unisce dall'alto verso il basso le attività
sequenzializzate. Le attività che cronologicamente sono eseguite prima si
trovano più in alto.}\\
\end{tabular}

\begin{tabular}{c c}
\hline
\parbox[c][2cm][c]{0.2 \textwidth}{
\includegraphics[scale=0.40]{blide/dia/BlideFlow}} 
&
\parbox[c][2cm][c]{0.6 \textwidth}{L'attività di composizione parallela è
rappresentata come una barra orizzontale sotto di cui, da sinistra a destra,
vengono rappresentati i flussi di esecuzione.}\\
\end{tabular}

%\rule{0cm}{1.5cm}

\begin{tabular}{c c}
\hline
\parbox[c][4cm][c]{0.2 \textwidth}
{\includegraphics[scale=0.30]{blide/dia/BlideContext}} & 
\parbox[c][4cm][c]{0.6 \textwidth}{I contesti sono rappresentati come
rettangoli tratteggiati, al cui interno viene svolta la Context Activity. Se il
contesto attiva un Protected Scope, questo viene rappresentato a partire
dell'angolo in alto a destra come un rettangolo con il bordo tratteggiato di
colore rosso.}\\
\end{tabular}

\begin{tabular}{c c}
\hline
\parbox[c][2.5cm][c]{0.2 \textwidth}
{\includegraphics[scale=0.42]{blide/dia/BlidePick}} & 
\parbox[c][2.5cm][c]{0.6 \textwidth}{La scelta esterna è rappresentata tramite
la disposizione orizzontale delle attività di ricezione unite dal simbolo +.}\\
\end{tabular}

\begin{tabular}{c c}
\hline
\parbox[c][3.5cm][c]{0.2 \textwidth}{
\begin{center} 
\includegraphics[scale=0.7]{blide/dia/BlideIf}
\end{center}
} & 
\parbox[c][3.5cm][c]{0.6 \textwidth}{La valutazione della scelta condizionata
è rappresentata dall'icona a sinistra. Nel caso in cui la condizione di test
è valutata a false, l'icona ha contorno rosso (come nell'immagine
riportata); viceversa, se valuta a true, ha contorno verde.}\\
\end{tabular}

\begin{tabular}{c c}
\hline
\parbox[c][2.5cm][c]{0.2 \textwidth}{
\begin{center} 
\includegraphics[scale=0.7]{blide/dia/BlideWhile}
\end{center}
} & 
\parbox[c][2.5cm][c]{0.6 \textwidth}{Le operazioni eseguite in un ciclo
d'iterazione sono precedute dall'icona rappresentata a sinistra.}\\
\hline
\end{tabular}

% \caption{tablecaption}
% \label{tablelabel}
% \end{table}

\vspace{0.5cm}
\section{Un esempio d'uso}

In questa sezione presentiamo un esempio d'uso degli strumenti
realizzati. L'esempio considerato è stato introdotto nel documento di specifca
\emph{BPEL 1.1} \cite{BPEL11Spec} (sezione 16.1) e ripreso in
\cite{LaPuTie1}.

L'esempio, pur risultando essere una semplificazione di uno scenario reale,
permette di sperimentare un buon numero delle caratteristiche del linguaggio,	
come i partner link dinamici, i correlation set, i fault handler e i
compensation handler.
\\

Si realizza un servizio di spedizioni (\emph{Shipping Service}) che gestisce
gli ordini di clienti. Gli ordini sono composti da un numero di
articoli e il servizio mette a disposizione due tipi di spedizioni: una in cui
tutti gli articoli dell'ordine sono inviati insieme, e l'altra, in cui è
possibile spedire in parti gruppi di articoli, in base alla disponibilità degli stessi in
un ipotetico magazzino.

Il servizio di spedizione da noi realizzato interagisce con altri due servizi
di backend, un servizio di gestione del magazzino (\emph{Store Service}) e un
servizio di addebito dei pagamenti (\emph{Billing Service}). I due servizi
sono realizzati con interfacce stateless, la cui implementazione è
esclusivamente rivolta a fornire un supporto per un'esecuzione verosimile del
processo realizzato dal servizio spedizioni e non vuole essere in nessun modo
una soluzione alle problematiche presenti in scenari reali.

\begin{figure}[tp]
\begin{center}
  \includegraphics[scale=0.80,clip]{blide/dia/shipper}
   \caption[Codice Blite, il Servizio Spedizioni]{Il codice Blite che realizza
   lo
   \emph{Shipping Service}.}
  \label{fig:shipper}
\end{center}
\end{figure}

Il servizio spedizioni è realizzato con la definizione di processo Blite di
Figura \ref{fig:shipper}. Il Deployment definisce un correlation set con la
variabile \texttt{id} che rappresenta un identificativo univoco per gli ordini.
Tale identificativo è utilizzato per creare la correlazione dei messaggi che
arrivano dai servizi di backend con l'istanza appropriata del processo
spedizioni. Anche i processi client del servizio spedizioni utilizzano tale
valore per correlare le diverse istanze con i messaggi scambiati.

La definizione di processo presenta:  
$$
	\verb#rcv<"ship", cust> req(id, c, items)#
$$
come attività di creazione delle istanze, in cui la ricezione è fatta tramite un
partner link bidirezionale, in cui la locazione del richiedente è resa dinamica
tramite l'identificativo \texttt{cust}. I valori ricevuti rappresentano
rispettivamente: \texttt{id}, l'identificativo dell'ordine (già introdotto e
utilizzato per correlare la comunicazione); \texttt{c}, un valore booleano che
discrimina fra le due modalità di invio degli articoli; \texttt{items}, un
intero che rappresenta il numero degli articoli nell'ordine.

Se \texttt{c} ha il valore \texttt{true} il processo prova ad inviare tutti gli
articoli in una sola spedizione. Tramite l'invocazione:
$$
	\verb#inv<"bend", "ship"> packall(id, items)#
$$
richiede al servizio di magazzino l'imballaggio di tutti gli articoli e
tramite:
$$
	\verb#rcv<"ship"> packallcb(id, ok)#
$$
attende la risposta di questo. In questo caso il partner link è pure
bidirezionale, ma le due parti sono staticamente note: \verb#"bend"# 
identifica il servizio di magazzino e \verb#"ship"# il 
servizio spedizione. Il valore di \texttt{ok} discrimina se la
spedizione sia possibile o meno. Se questo ha valore \texttt{true}, il processo
sottomette il conto e invia la nota di spedizione tramite le invocazioni:
$$
\begin{array}{c}
	\verb#inv<"bill"> bill(id, items);#\\
	\verb#inv<cust> notice(id, items)#
\end{array}
$$
in cui è utilizzato il valore attuale di \texttt{cust} per identificare il
client; altrimenti, se il valore di \texttt{ok} è \texttt{false}, si comunica un
errore con: 
$$
	\verb#inv<cust> err(id, "sorry")#
$$

Quando \texttt{c} ha il valore \texttt{false} il processo può inviare gli
articoli in maniera differita. Per prima cosa il processo inizializza uno scope
(o contesto) in cui viene svolta l'attività principale ed è definito un fault
handler per mezzo del quale, in caso di eccezione, si comunica l'errore al
client.

La politica del servizio è quella di attribuire subito tutto il costo della
spedizione, per cui si esegue il sotto scope seguente, in cui vi è l'interazione
con il servizio di backend per la gestione dei pagamenti:
\begin{verbatim}
         [  //accredito pagamento
            inv<"bill"> bill(id, items)
            ch: //compensazione accredito
               seq
                  noshiped := items - shiped;
                  inv<"bill"> revoke(id, noshiped);
               qes
         ] 
\end{verbatim}
Se l'attribuzione del pagamento avviene con successo tramite l'invocazione: 
$$
	\verb#inv<"bill"> bill(id, items)#
$$
viene istallato un compensation handler che, tramite la seguente sequenza di
azioni, annulla il pagamento degli articoli che non sono stati effettivamente
inviati:
\begin{verbatim}
               seq
                  noshiped := items - shiped;
                  inv<"bill"> revoke(id, noshiped);
               qes
\end{verbatim}
Si deve osservare che, nel momento in cui il compensation handler verrà
eseguito, la variabile \texttt{shiped} sarà effettivamente valorizzata al
numero degli articoli inviati. Questo in accordo con la semantica di Blite per
cui lo stato della memoria dell'istanza è unico e condiviso da tutte le 
attività, comprese quelle eseguite nei vari fault e compesation handler.

Terminato quest'ultimo scope il processo inizia un'iterazione, in cui ad ogni
passo interroga il servizio di magazzino, richiedendo l'invio degli articoli
attualmente disponibili. Le due attività seguenti eseguono in maniera asincrona
l'interazione:
\begin{verbatim}
            inv<"bend", "ship"> pack(id, shiped, items);
            rcv<"ship"> packcb(id, count);
\end{verbatim}
La prima invocazione invia i seguenti valori al servizio di backend:
\texttt{id}, identificativo dell'ordine,
\texttt{shiped}, numero degli articoli attualmente inviati, \texttt{items},
numero complessivo degli articoli. La
successiva ricezione, utilizzando ancora il valore dell'\texttt{id} per
attuare la correlazione, valorizza nella variabile \texttt{count} il numero
degli articoli inviati in questo passo.

Se il valore di \texttt{count} è maggiore di zero, il processo invia al client
una nota di spedizione con tale valore ed aggiorna la variabile
\texttt{shiped} con il numero di tutti gli articoli attualmente inviati. Al
contrario, se \texttt{count} ha valore minore o uguale a zero, il processo
solleva un'eccezione e l'esecuzione esce forzatamente dal ciclo iterativo.

L'eccezione viene gestita nello scope che contiene l'iterazione. 
In questo, come precedentemente è stato fatto osservare, verrà eseguito 
il compensation handler del sottoscope completato,
revocando il pagamento degli articoli non inviati.
Poiché lo scope che gestisce l'eccezione definisce un
faulthandler, questo verrà eseguito subito dopo il compensation handler,
comunicando così al client l'errore.

Se le politiche e le disponibilità del magazzino sono tali che, anche
in più passi differiti, il valore di \texttt{shiped} diventi uguale a quello di
\texttt{items}, l'iterazione termina e il processo si conclude avendo eseguito
l'invio di tutti gli ordini.

Si deve osservare che il processo di invio articoli termina positivamente anche
quando è sollevata l'eccezione, in quanto questa è gestita internamente.
\\

\begin{figure}[t!]
\begin{center}
  \includegraphics[scale=0.80,clip]{blide/dia/clients}
   \caption[Codice Blite, Clienti del Servizio Spedizioni]{Il codice Blite che
   definisce i client del Servizio Spedizioni.}
  \label{fig:clients}
\end{center}
\end{figure}

In Figura \ref{fig:clients} è presentato il codice Blite in cui è definita la
composizione di due Deployment, ciascuno dei quali definisce una
Ready-to-Run-Instance che realizza un processo client per lo Shipping Service.
Il primo dei due richiede l'invio completo dell'ordine, il secondo l'invio
anche differito. Di seguito tali processi verrano identificati rispettivamente
come: \emph{All} e \emph{Dif}.

Il codice è abbastanza semplice ed intuibile. In entrambi i casi i processi 
eseguono l'inizializzazione preliminare delle variabili utilizzate, in
particolare: alla variabile \texttt{id} è assegnato il valore
identificativo dell'ordine, tale variabile è anche utilizzata per realizzare la
correlazione, alla variabile \texttt{c} viene assegnato un valore booleano per
discriminare la tipologia di invio articoli richiesta, alla variabile
\texttt{items} viene assegnato il numero di articoli che compongono l'ordine.

Fatto questo entrambi i processi eseguono un'invocazione del servizio di
spedizioni, producendone rispettivamente la creazione di un'istanza.
L'invocazione comunica anche la locazione dei servizi client andando a
valorizzare dinamicamente il partner link con i rispettivi identificativi.
Il client All esegue:
$$
	\verb#inv<"ship", "cust-all"> req(id, c, items)#
$$
e il client Dif: 
$$
	\verb#inv<"ship", "cust-dif"> req(id, c, items)#
$$

A questo punto i comportamenti dei due client differiscono in base alla
tipologia di invio articoli richiesta. In particolare All espone allo Shipping Service
semplicemente la scelta fra le due operazioni \texttt{notice} ed \texttt{err},
tramite la seguente Pick Activity:
\begin{verbatim}
      pck
         rcv<"cust-all"> notice(id, items);
         empty;
       +
         //tale invio non e' disponibile
         rcv<"cust-all"> err(id, err);
         exit; //si fallisce l'istanza
      kcp 
\end{verbatim}
Se viene attivata la prima opzione l'istanza di processo termina con successo;
mentre nel caso della seconda viene eseguita l'attività \texttt{exit}, che
produce la terminazione forzata e il fallimento dell'istanza.

L'istanza client Diff invece esegue la Pick Activity all'interno del seguente
ciclo \texttt{while}: 
\begin{verbatim}
         while (shiped < items)
            pck
                rcv<"cust-dif"> notice(id, count);
                shiped := shiped + count;
             +
                rcv<"cust-dif"> err(id, err);
                exit; //si fallisce l'istanza
            kcp 
\end{verbatim}
in cui viene accumulato nella variabile \texttt{shiped} il numero degli
articoli attualmente inviati. L'iterazione termina quando tale valore diviene
uguale a quello di \texttt{items} e l'istanza completa positivamente
l'esecuzione. Nel caso in cui venga attivata dal servizio spedizioni l'opzione
associata all'operazione \texttt{err}, l'attività \texttt{exit} produce l'uscita
immediata dall'iterazione e il fallimento dell'istanza.

Per completezza in Figura \ref{fig:store} e in Figura \ref{fig:billing} vengono
riportati anche i programmi Blite che definiscono rispettivamente lo Store
Service e il Billing Service. Facciamo osservare ancora che tale codice ha semplicemente la
funzione di definire delle interfacce verosimili utilizzabili dal servizio
spedizioni; l'implementazione invece è di volta in volta adeguata in base alle
esigenze delle simulazioni realizzate.
\\

\begin{figure}[p!]
\begin{center}
  \includegraphics[scale=0.80,clip]{blide/dia/store}
   \caption[Codice Blite, interfaccia Store Service]{Il codice Blite che
   definisce il Servizio di gestione del magazzino.}
  \label{fig:store}
\end{center}
\end{figure}

\begin{figure}[p!]
\begin{center}
  \includegraphics[scale=0.80,clip]{blide/dia/billing}
   \caption[Codice Blite, interfaccia Billing Service]{Il codice Blite che
   definisce il Servizio di gestione pagamenti.}
  \label{fig:billing}
\end{center}
\end{figure}

Di seguito vengono mostrate alcune simulazioni effettuate tramite Blide. In
Figura \ref{fig:Sim1} è rappresentato lo scenario, in cui un'istanza client
richede l'invio di tutti gli articoli allo Shipping Service. Poichè la
disponibiltà di magazzino è tale da soddifare la richiesta, il servizio di
spedizione risponde invocando l'operazione \texttt{notice} del servizio client.
Si attua la correlazione del messaggio con l'istanza e questa termina con
successo la propria esecuzione.

In Figura \ref{fig:Sim2} ad una richiesta di invio dell'ordine completo, il
servizio di spedizione risponde invocando l'operazione \texttt{err}, questo
produce la terminazione forzata e il fallimento dell'istanza client.

In Figura \ref{fig:Sim3} è rappresentata la comunicazione fra un client che
supporta l'invio differito degli articoli e il servizio di spedizione. Come si
può osservare le esecuzioni presentano la ripetizione delle attività contenute
all'interno del ciclo \texttt{while}. In particolare il servizio spedizioni
interagisce due volte con il magazzino e con il client, facendo sì che
quest'ultimo porti a termine positivamente la propria esecuzione.

In Figura \ref{fig:Sim4} sono illustrati ancora i processi associati al
tentativo di spedizione differita. In questo caso però al servizio spedizioni,
nel secondo ciclo dell'iterazione, viene comunicata l'indisponibilità degli
articoli. Si genera così un'eccezione che avvia il
\emph{Proteced Scope}, in cui viene prima compensata l'attività di accredito
pagamenti e poi comunicato l'errore al client. Quest'ultimo processo, ricevuto
tale messaggio di errore, termina forzatamente la propria esecuzione. 

\begin{figure}[p]
\begin{center}
  \includegraphics[scale=0.85,clip]{blide/dia/Sim1}
   \caption[Blide, simulazione 1]{La spedizione completa dell'ordine è
   possibile, l'istanza client All termina con successo la propria esecuzione}
  \label{fig:Sim1}
\end{center}
\end{figure}

\begin{figure}[p]
\begin{center}
  \includegraphics[scale=0.85,clip]{blide/dia/Sim2}
   \caption[Blide, simulazione 2]{La spedizione completa dell'ordine
   non è possibile, l'istanza client All fallisce.}
  \label{fig:Sim2}
\end{center}
\end{figure}

\begin{figure}[p]
\begin{center}
  \includegraphics[scale=1,clip]{blide/dia/Sim3}
   \caption[Blide, simulazione 3]{Spedizione differita degli articoli
   di un ordine.}
  \label{fig:Sim3}
\end{center}
\end{figure}

\begin{figure}[p]
\begin{center}
  \includegraphics[scale=0.90,clip]{blide/dia/Sim4}
   \caption[Blide, simulazione 4]{Il processo di spedizione differita fallisce,
   il compensation e il fault handler sono eseguiti in un Proteced Scope
   (rettangolo tratteggiato di rosso).}
  \label{fig:Sim4}
\end{center}
\end{figure}


